-
Notifications
You must be signed in to change notification settings - Fork 999
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A variety of improvements around tool parameter modeling (second try) #19027
base: dev
Are you sure you want to change the base?
A variety of improvements around tool parameter modeling (second try) #19027
Conversation
Was causing a randomly failing test.
def static_validators(validator_models: List[AnyValidatorModel]) -> List[AnyValidatorModel]: | ||
static_validators = [] | ||
for validator_model in validator_models: | ||
print(validator_model._static) |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
print(validator_model._static) |
self.datalist = [] | ||
for title, value, _ in input_source.parse_static_options(): | ||
self.datalist.append({"label": title, "value": value}) | ||
|
||
# why does Integer and Float subclass this :_( |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
why does it? :)
): | ||
super().__init__(message, negate) | ||
assert filename | ||
assert os.path.exists(filename), f"File {filename} specified by the 'filename' attribute not found" |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Is that really needed here as assert?
@@ -26,7 +26,7 @@ def stock_tool_sources(): | |||
|
|||
|
|||
def _walk_directory_for_tools(path): | |||
if path.is_file() and path.name.endswith(".xml"): | |||
if path.is_file() and path.name.endswith(".xml") and "macros" not in path.name and "_conf.xml" not in path.name: |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
can you add a comment what you are trying here?
self._inputs = inputs | ||
return self | ||
|
||
# aliases for self to create silly little English sentense... inputs.when.flat().when.legacy() |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
:-)
<inputs> | ||
<param name="ref_parameter" type="data" ext="tabular" > | ||
</param> | ||
g <param name="parameter" type="drill_down" dynamic_options="collate_table(ref_parameter.dataset.get_file_name())"> |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
g <param name="parameter" type="drill_down" dynamic_options="collate_table(ref_parameter.dataset.get_file_name())"> | |
<param name="parameter" type="drill_down" dynamic_options="collate_table(ref_parameter.dataset.get_file_name())"> |
How could this pass tests?
A redo of #18952 on top of the new tool execution testing stuff and with a few more fixes.
Old PR Description:
This contains tests, fixes, and refactorings of the tool parameter models aimed at enabling two applications/APIs - these applications are a tool landing API and the tool request API. Those APIs and corresponding runtimes are not included here but can be found in the structured tool state branch (tool request API and tool landing API).
The bulk of the enhancements around enabling tool landing are found in a single commit titled "models for tool landing request state...". This introduces two new tool state representation types and wide variety of parameter specification tests that describe how the API will work and how models will be stored. The API will consume tool state with the representation type "landing_request" and will store the representation "landing_request_internal" in the database. The internal version is the decoded version of that tool state. The idea behind the landing API is that essentially everything is optional - external entities could for instance host a collection of FASTA files and provide links to tools to align against these for instance - all the parameters but the database would be deferred to the users discretion. The parameters that are provided though will be validated.
The remainder of the commits are a collection of things that make more confident were not doing damage with the tool request API. Part of that effort is having a fully expanded representation of the tool state that describes something pretty close to what we feed the wrappers - defaults expanded out, no absent conditionals, etc... That effort resulting in me writing lots of API tests to describe how the current API works so we don't regress it, implementing validation of static parameter validators so we can mimic some of the runtime behavior of the tools and write stronger upfront validation of the requests, etc...
How to test the changes?
(Select all options that apply)
License